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METHOD AND APPARATUS FOR GENERATING QUERY AND RESPONSE 
STATEMENTS AT RUNTIME FROM GENERIC REQUESTS 

CROSS REFERENCE TO RELATED APPLICATIONS 

The present invention is related to the following 
applications entitled "METHOD AND APPARATUS FOR 
VALIDATING AND CONFIGURING DATABASE TRANSACTION REQUESTS 
FROM MULTIPLE CLIENTS" , serial no. 10/756,932, attorney 
docket no. AUS920030927US1, filed on January 14, 2004, 
and "METHOD AND APPARATUS FOR SPLITTING AND MERGING 

REQUEST AND RESPONSE DATA AT RUNTIME", serial no. , 

attorney docket no. AUS920040040US1 , filed on , 

assigned to the same assignee, and incorporated herein by 
reference . 

BACKGROUND OF THE INVENTION 

1. Technical Field: 

The present invention relates generally to an 
improved data processing system and, in particular, to a 
method and system for accessing objects in a data store. 
Still more particularly, the present invention relates to 
a method, apparatus, and computer instructions for 
generating query statements at run time from generic and 
abstract request and response messages without having 
knowledge of the data store. 
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2. Description of Related Art: 

With the rise of the Internet, the ease of 
information exchange is pertinent to any application that 
facilitates data transactions. Particularly, in a World 
Wide Web environment, where service providers and 
consumers meet to conduct business, the efficiency of 
storing and retrieving business data is important to the 
success of business transactions. Various solutions have 
been developed to facilitate information exchange and 
storage of business data. 

One solution for data exchange uses an XML Extender. 
An XML Extender is a component of DB2 Universal Database, 
a product available from International Business Machine 
Corporation. XML Extender makes use of extensible markup 
language (XML) , a markup language available from the 
World Wide Web Consortium (W3C) , to generate requests for 
business objects in a data store. XML allows users to 
flexibly define the structure of a query using a set of 
XML schemas. XML schemas define a set of elements 'that 
an XML message should include in order to exchange- 
information with a data store. Thus, an XML message must 
adhere to the XML schemas in order to interact with the 
data store. 

However, the XML Extender requires a client 
application to have knowledge of the specific data store, 
for example, a table name and table column name, in order 
to send an XML query message. In addition, the client 
application is required to have the ability to issue a 
structured query language (SQL) statement to be executed 
against the data store. SQL is an industry standard for 
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constructing database queries. Furthermore, the amount 
of code required to support the variety of actions 
performed on the object is large since each action in the 
XML query may be different. 

Therefore, it would be advantageous to have a 
generic set of XML schemas and messages that are not data 
store specific. In addition, it would be advantageous to 
have a set of generic XML schemas that facilitate 
generation of SQL statements from an XML query that does 
not include a SQL statement. 
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SUMMARY OF THE INVENTION 

The present invention provides a method, apparatus, 
and computer instructions for generating SQL statements 
at run time from generic and abstract XML request and 
response messages without having knowledge of the data 
store. In a preferred embodiment, the present invention 
provides a set of generic XML schemas that define a 
number of actions a client may perform on information for 
a given object. Actions may include add, get, delete, 
list, update, and validate. A client may send a generic 
request XML message to perform one of these actions to 
the adaptor, which then generates and executes SQL 
statements on the specific data store. The resulting 
values are returned from the data store to the adaptor in 
the form of a response XML message that adhere to the set 
of generic XML schemas. The resulting values are 
obtained from the response XML message and returned to 
the client. 



5 

Docket No. AUS920030928US1 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

Figure 1 is a pictorial representation of a network 
of data processing systems in which the present invention 
may be implemented; 

Figure 2 is a block diagram of a data processing 
system that may be implemented as a server in accordance 
with a preferred embodiment of the present invention; 

Figure 3 is a block diagram illustrating a data 
processing system in which the present invention may be 
implemented; 

Figure 4 is a diagram illustrating components used 
for generating SQL statements from generic and abstract 
XML request and response messages in accordance with a 
preferred embodiment of the present invention; 

Figure 5 is a diagram illustrating a set of XML 
schemas used for generating SQL statements in accordance 
with a preferred embodiment of the present invention; 

Figure 6A is a diagram illustrating example 
implementation of esmBase.xsd in accordance with a 
preferred embodiment of the present invention; 
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Figure 6B is a diagram illustrating an example 
implementation of esmBase.xsd in accordance with a 
preferred embodiment of the present invention; 

Figure 7A is a diagram illustrating an example 
implementation of etcml.xsd in accordance with a 
preferred embodiment of the present invention; 

Figure 7B is a diagram illustrating an example 
implementation of etcml.xsd in accordance with a 
preferred embodiment of the present invention; 

Figure 7C is a diagram illustrating an example 
implementation of etcml.xsd in accordance with a 
preferred embodiment of the present invention; 

Figure 7D is a diagram illustrating an example 
implementation of etcml.xsd in accordance with a 
preferred embodiment of the present invention. 

Figure 8 is a diagram illustrating an example 
implementation of etcml_redef ines.xsd .in accordance with 
a preferred embodiment of the present invention; 

Figure 9 is a flowchart illustrating an exemplary 
process for generating SQL statements at runtime from 
generic XML request and response messages in accordance 
with a preferred embodiment of the present invention; 

Figure 10 is a diagram illustrating an example 
request using a request XML message in accordance with a 
preferred embodiment of the present invention; and 

Figure ll is a diagram illustrating an example 
generated SQL statement and a response using a response 
XML message depicted in accordance with a preferred 
embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference now to the figures, Figure 1 depicts a 
pictorial representation of a network of data processing 
systems in which the present invention may be implemented. 
Network data processing system 100 is a network of 
computers in which the present invention may be 
implemented. Network data processing system 100 contains 
a network 102, which is the medium used to provide 
communication links between various devices and computers 
connected together within network data processing system 
100. Network 102 may include connections, such as wire, 
wireless communication links, or fiber optic cables. 

In the depicted example, server 104 is connected to 
network 102 along with storage unit 106. In addition, 
clients 108, 110, and 112 are connected to network 102. 
These clients 108, 110, and 112 may be, for example, 
personal computers or network computers. In the depicted 
example, server 104 provides data, such as boot files, 
operating system images, and applications to clients 108- 
•112. Clients 108, 110, and 112 are clients to server 104. 
'Network data processing system 100 may include additional 
servers, clients, and other devices not shown. 

In the depicted example, network data processing 
system 100 is the Internet with network 102 representing a 
worldwide collection of networks and gateways that use the 
Transmission Control Protocol/Internet Protocol (TCP/IP) 
suite of protocols to communicate with one another. At 
the heart of the Internet is a backbone of high-speed data 
communication lines between major nodes or host computers, 
consisting of thousands of commercial, government, 
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educational and other computer systems that route data and 
messages. Of course, network data processing system 100 
also may be implemented as a number of different types of 
networks, such as for example, an intranet, a local area 
network (LAN) , or a wide area network (WAN) . Figure 1 is 
intended as an example, and not as an architectural 
limitation for the present invention. 

Referring to Figure 2, a block diagram of a data 
processing system that may be implemented as a server, 
such as server 104 in Figure 1, is depicted in accordance 
with a preferred embodiment of the present invention. 
Data processing system 200 may be a symmetric 
multiprocessor (SMP) system including a plurality of 
processors 202 and 204 connected to system bus 206. 
Alternatively, a single processor system may be employed. 
Also connected to system bus 206 is memory 
controller/cache 208, which provides an interface to local 
memory 209. I/O bus bridge 210 is connected to system bus 
206 and provides an interface to I/O bus 212. Memory 
controller/cache 208 and I/O bus bridge 210 may be 
integrated as depicted. 

Peripheral component interconnect (PCI) bus bridges 
214 connected to I/O bus 212 provides an interface to PCI 
local bus 216. A number of modems may be connected to PCI 
local bus 216. Typical PCI bus implementations will 
support four PCI expansion slots or add- in connectors. 
Communication links to clients 108-112 in Figure 1 may be 
provided through modem 218 and network adapter 220 
connected to PCI local bus 216 through add-in boards. 
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Additional PCI bus bridges 222 and 224 provide 
interfaces for additional PCI local buses 226 and 228, 
from which additional modems or network adapters may be 
supported. In this manner, data processing system 200 
allows connections to multiple network computers. A 
memory-mapped graphics adapter 230 and hard disk 232 may 
also be connected to I/O bus 212 as depicted, either 
directly or indirectly. 

Those of ordinary skill in the art will appreciate 
that the hardware depicted in Figure 2 may vary. For 
example, other peripheral devices, such as optical disk 
drives and the like, also may be used in addition to or in 
place of the hardware depicted. The depicted example is 
not meant to imply architectural limitations with respect 
to the present invention. 

The data processing system depicted in Figure 2 may 
be, for example, an IBM eServer pSeries system, a product 
of International business Machines Corporation in Armonk, 
New York, running the Advanced Interactive Executive 
(AIX) operating system or LINUX operating system. 

With reference now to Figure 3, a block diagram 
illustrating a data-processing system is depicted in which 
the present invention may be implemented. Data processing 
system 300 is an example of a client computer. Data 
processing system 300 employs a peripheral component 
interconnect (PCI) local bus architecture. Although the 
depicted example employs a PCI bus, other bus 
architectures such as Accelerated Graphics Port (AGP) and 
Industry Standard Architecture (ISA) may be used. 
Processor 302 and main memory 304 are connected to PCI 
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local bus 306 through PCI bridge 308. PCI bridge 308 also 
may include an integrated memory controller and cache 
memory for processor 302. Additional connections to PCI 
local bus 306 may be made through direct component 
interconnection or through add- in boards. In the depicted 
example, local area network (LAN) adapter 310, SCSI host 
bus adapter 312, and expansion bus interface 314 are 
connected to PCI local bus 306 by direct component 
connection. In contrast, audio adapter 316, graphics 
adapter 318, and audio/video adapter 319 are connected to 
PCI local bus 306 by add- in boards inserted into expansion 
slots. Expansion bus interface 314 provides a connection 
for a keyboard and mouse adapter 320, modem 322, and 
additional memory 324. Small computer system interface 
(SCSI) host bus adapter 312 provides a connection for hard 
disk drive 326, tape drive 328, and CD-ROM drive 330. 

An operating system runs on processor 302 and is used 
to coordinate and provide control of various components 
within data processing system 300: in Figure 3. The 
operating system may be a commercially available operating 
system, such as Windows XP, which ris available from 
Microsoft Corporation. An object oriented programming 
system such as Java may run in conjunction with the 
operating system and provide calls to the operating system 
from Java programs or applications executing on data 
processing system 300. "Java" is a trademark of Sun 
Microsystems, Inc. Instructions for the operating system, 
the object-oriented operating system, and applications or 
programs are located on storage devices, such as hard disk 
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drive 326, and may be loaded into main memory 304 for 
execution by processor 302, 

Those of ordinary skill in the art will appreciate 
that the hardware in Figure 3 may vary depending on the 
implementation. Other internal hardware or peripheral 
devices, such as flash read-only memory (ROM), equivalent 
nonvolatile memory, or optical disk drives and the like, 
may be used in addition to or in place of the hardware 
depicted in Figure 3. Also, the processes of the present 
invention may be applied to a multiprocessor data 
processing system. 

The depicted example in Figure 3 and above -described 
examples are not meant to imply architectural 
limitations. For example, data processing system 300 
also may be a notebook computer or hand held computer in 
addition to taking the form of a PDA. Data processing 
system 300 also may be a kiosk or a Web appliance. 

The present invention provides an improved method, 
apparatus and computer instruction for generating an SQL 
statement from generic XML request and response messages. 
The present invention provides a set of generic XML 
schemas for generating SQL - statements to retrieve or 
submit information to a specific data store without 
requiring a client application to have knowledge of how 
to access the data store. An example of a data store is 
DB2 Universal Database, a product available from 
International Business Machines Corporation. 

An XML message of the present invention is defined 
using a set of generic XML schemas that are not data 
store specific. Thus, any client application may 
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interact with any type of data store using the features 
of the present invention without the need of special XML 
schema definitions or application programming interfaces 
(APIs) . Furthermore, the present invention supports 
complex objects, such as nested lists or nested objects. 
A nested object includes sub-objects. For example, a 
ProblemTicket object may include a ProblemTicket . Person 
sub-object . 

In the present invention, each type of request to 
the data store includes only one business process and 
therefore reduces the amount of code required to support 
all other possible requests. For example, a request to 
get records from the data store for a specific object may 
be implemented using the same request XML message as a 
request to update the data store. 

In a preferred embodiment, the present invention 
.includes a set of generic XML schemas that define a 
number of actions a client application may perform. on 
information for a given object. An object is a-'data 
entity that includes a set of attributes and subobjects. 
For : example, a ProblemTicket is an object that includes 
attribute id and subobject Person. The object ^may be 
stored in a data store along with its attributes and 
subobjects. Using this set of generic XML schemas, the 
client application may send a request XML message to be 
processed by an adaptor. An adaptor generates and 
executes SQL statements against a data store to submit or 
retrieve information to or from the object. In an 
example implementation, the adaptor is a component of 
WebSphere Application Server for data access, which is a 
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product available from International Business Machines 
Corporation. When results are returned from execution of 
the generated SQL statement, the adaptor returns the 
results using a response XML message that adheres to the 
generic XML schemas . The client application may obtain 
the results from the response XML message. 

Examples of actions a client application may 
perform on objects include, for example, add, delete, 
get, list, modify, and validate. The "add" action 
creates a new record in the data store for the selected 
object. An object may be any object that includes a 
number of attributes. For example, an object may be a 
problem ticket that includes a number of attributes, such 
as id, call back date, etc. The "delete" action deletes 
an existing record for the selected object from the data 
store. The "get" action retrieves an existing record for 
the selected object from the data store. The "list" 
action returns a list of requested fields for objects 
that match the filter^ criteria. The "modify" action 
updates an existing record for the selected object. The 
"validate" action validates the selected object with a 
value using a condition operator. 

Turning now to Figure 4, a diagram illustrating 
components used for generating SQL statements from 
generic XML request and response messages is depicted in 
accordance with a preferred embodiment of the present 
invention. As depicted in Figure 4, client 402 may 
execute an application, such as application 404, to 
submit or retrieve information to or from Web page 408 
that is stored in Web server 406. Client 402 may be 
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implemented as data processing system 100 in Figure 1 and 
Web server 406 may be implemented as server 104 in Figure 
1. An example of Web server 406 may be WebSphere 
Application Server, a product available from 
International Business Machines Corporation. Application 
404 may be implemented as a Web browser, a Java 
application, a plugin to a Web browser or any other types 
of client applications. 

Client 402 requests information, such as a problem 
ticket with a specific id, from application 404 to Web 
page 408. Web page 408 may request information from the 
adaptor 410, which interacts with data store 412, to 
retrieve information. Data store 412 may be implemented 
on server 414 or within Web server 406. In these 
examples, Web page 408 may be implemented as a servlet. 

In conventional systems, in order to retrieve 
information from data store 412, Web page 408, which 
interprets a request from application 404, is required to 
include logic for specifying a particular data store 412 
to which the request is idirected. The logic specifying 
the data store includes,. a table name of the object 
requested, table columri name for requested fields, etc. 
In addition, Web page 408 logic is required to include 
SQL for the request data in order to submit a query in a 
format that is understood by data store 412 . In 
accordance with embodiments of the invention, logic for 
specifying the particular data store and SQL logic is not 
required to be included in Web page 408. 

In this example implementation, Web server 406 
includes an engine, adaptor 410, which is a set of APIs 
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that interacts with data store 412 by generating and 
executing SQL statements using parameters provided by 
client 402 through web page 408. Adaptor 410 is a data 
access framework provided by WebSphere Application Server 
in these illustrated examples. Using the features of the 
present invention, upon receipt of a request from 
application 404, logic of Web page 406 in Web server 408, 
which interprets the request from application 404 , 
assembles a request XML message that is defined by a set 
of generic XML schemas. The set of generic schemas 
identifies the type of requests, the requested fields of 
the object and any other parameters required to generate 
an SQL statement. Upon completion of the assembly, logic 
of Web page 408 may forward the request XML message to 
adaptor 410, which then generates and executes an SQL 
statement using values of the request XML message. 

Once information is retrieved from data store 412, 
adaptor 410 returns the information to logic of Web page 
408 in a form of a generic response XML message. Logic 
of Web page 408 then disassembles the values in the 
response XML message into a response to application 404 
on client 402. Thus, using the ^features of the present 
invention, logic of Web page 408 may request information 
from a specific type of data store without specifying the 
data store or SQL- formatted request data. 

Turning next to Figure 5, a diagram illustrating a 
set of XML schemas used for generating SQL statements is 
depicted in accordance with a preferred embodiment of the 
present invention. As depicted in Figure 5, the present 
invention includes a plurality of schemas including 
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schema object. xsd 502 # which describes the structure of a 
transaction. A transaction may include a request type, a 
response type and a response body, all of which are 
elements defined in the schema esmBase.xsd 504. Schema 
esmBase.xsd 504 defines what a request or response 
consists of. For example, a response may include a 
number of rows, which define names of objects requested. 
Additionally, rows may be nested. Within each row, there 
are a number of columns, which define names of the 
requested fields within objects requested. Within each 
column, there may be a number of enums, which return a 
number of options, such as options for a drop down box in 
a user interface. Schema esmBase.xsd 504 includes and 
extends elements defined in schema etcml.xsd 506. Hence, 
etcml.xsd 506 is the parent of esmBase.xsd 504. 

Schema etcml.xsd 506 defines the core structure for 
an etcML based language. In the context of the present 
invention, an etcML based language is a language used to 
define structures of all allowed transactions. For 
example, schema etcml.xsd 506 includes an etcRootType, 
which is an element that defines a collection of 
transactions that a client, such as client* 402 in Figure 
4, may perform over a set of generic request and response 
XML messages. For each transaction, at most one request 
or response is present. A response is defined by 
TransactionResponseType and a request is defined by 
TransactionRequestType . These types are described in 
further details in Figure 6A # 6B, 7A, 7B, 7C and 7D. 

For each transaction type, a ProviderActionType is 
defined for actions available for each transaction to 
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perform. Example actions for a transaction type include, 
add, delete, get, list, validate, and modify. 
ProviderActionType is defined in schema 

etcml_redef ine .xsd 508, which may easily be modified. A 
set of error messages for a response may also be defined 
by using a ProviderErrorCodeType, which is also defined 
in schema etcml_redef ined.xsd 508. 

Turning now to Figure 6A, a diagram illustrating an 
example implementation of schema esmBase.xsd 60 0 is 
depicted in accordance with a preferred embodiment of the 
present invention. As depicted in Figure 6A, in this 
example implementation, schema esmBase.xsd 600 defines 
the structure of a request or response. EsmML 602 is the 
root element extended from the etcRootType 604 defined in 
schema etcml.xsd. etcRootType 604 represents a 
collection of transactions. If the transaction is a 
response,: XML message, the response XML message includes a 
body, defined by ESMResponseBodyType 606. 

ESMResponseSodyType 606 includes a RowSetType element 608 
and a Proper.tiesType 610, both of which are described in 
further details in Figure 6B. In addition, schema 
esmBase.xsd 600 includes a ParameterType 612, which is 
extended from schema ectml.xsd 506. ParameterType 612 
defines a number of parameters that a client may request 
through a request XML message, such as, for example, a 
number of Request edFields 614, Start Row number 616, 
Display Row Count 618, etc. 

Turning next to Figure 6B, a diagram illustrating an 
example implementation of esmBase.xsd is depicted in 
accordance with a preferred embodiment of the present 
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invention. Figure 6B is a part of esmBase.xsd in 
continuation of Figure 6A. As depicted in Figure 6B, in 
this example implementation, a response includes a 
PropertiesType 620, which includes FieldType 622 , 
represented by block 623. FieldType 623 specifies name 
624 and value 626 of a RequestedField, which is 
originally requested by the client in Figure 6A. For 
example, the name of a RequestedField may be a 
ProblemTicket . id and the value may be SITEA-00000034 . 

As described in Figure 6A, in addition to 
PropertiesType 620, a response includes RowSetType 628, 
which includes a number of rows 629. RowSetType 628 may 
be used in the present invention as a response or as a 
request to perform add or modify actions for updating 
records of an object. Each row 62 9 within RowSetType 628 
represents an object returned from the data store after 
meeting a certain criteria. The number of rows may be 
specified by the client using Start Row number 616, and 
Display Row Count 618 in Figure 6A. Row 629 is depicted 
by RowType 630. RowType 630 includes a ColumnType^ 632 
and a nested RowSetType 634. Thus, a row may be embedded 
within another row for nested objects. 

ColumnType 632 represents a RequestedField requested 
by the client, such as ProblemTicket . id. In addition to 
a name, and a value as described above, ColumnType 632 
includes an enums, defined by EnumsType 638, represented 
in block 640. EnumsType 640 is used to provide a list of 
strings in a response XML message. For example, the list 
of strings may define options a user may choose in a drop 
down box of the user interface. 
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With reference to Figure 7A, a diagram illustrating 
an example implementation of schema etcml.xsd is depicted 
in accordance with a preferred embodiment of the present 
invention. As depicted in Figure 7A, schema etcml.xsd 
700 is the parent schema of schema esmBase.xsd as 
described in Figures 6A and SB. Schema etcml.xsd 700 
includes etcRootType 702, which includes a number of 
transactions defined by TransactionsContainerType 704. 
TransactionContainerType 704, represented in block 706, 
may either be a request, represented by 

Transact ionRequestType 708, or a response, represented by 
Transact ionResponseType 710. TransactionRequestType 712 
includes a TransactionType 714, which is represented in 
block 720. TransactionType 720 describes attributes of a 
transaction, such as, for example, userlD and password 
required, timestamp of the transaction, language, 
country, and time zone of the transaction. 

In addition to TransactionType 714, ,. 
TransactionRequestType 712 also includes ProviderType 
716. ProviderType 716 is represented ifl block 722, which 
defines all backend data store systems .available. In 
this example, data store e-ESM61 724 and e-ESM44 726 are 
available for storing and retrieving information of an 
object . 

With reference to Figure 7B, a diagram illustrating 
an example implementation of etcml.xsd is depicted in 
accordance with a preferred embodiment of the present 
invention. Figure 7B is part of etcml.xsd in 
continuation of Figure 7A. As depicted in Figure 7B, a 
client may send a custom request that includes built-in 
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functionality, such as sorting and filtering, for the 
results of the request. This functionality is provided 
by TransactionFilteredRequestType 730. 

Transact ionFilteredRequestType 73 0 provides Sort 734 
and Filters 732 functions. Sort 734 function is 
represented by block 736, which includes a SortOrderType 
738. SortOrderType, represented by block 742, includes 
an attribute SQLGroupByOperatorType 744. 
SQLGroupByOperatorType 744, represented by block 746, 
allows the client to sort the results of the request in 
either ascending 748 or descending 750 order. This 
operator is part of an SQL statement that will be 
generated. 

As described above, the client may also filter the 
results using Filters 732 function. Filters 732 is 
represented by block 752 . Block 752 includes a number of 
Filter 754 and a required attribute of 
SQLConditionJoinOperatorType 758 both of which are 
described in further details in Figure 7C. Unlike 
sorting? ^filtering may be nested. Therefore, Filters' '3756 
is included within Filters 752. e ;< 

With reference to Figure 7C, a diagram illustrating 
an example implementation of etcml.xsd is depicted in 
accordance with a preferred embodiment of the present 
invention. Figure 7C is part of etcml.xsd in 
continuation of Figures 7A and 7B. As described in 
Figure 7B, Filters includes a SQLConditionJoinOpertorType 
758 represented by block 760, which includes join 
operators And 762 or Or 764. The join operator becomes 
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part of an SQL statement that will be generated by the 
adaptor . 

In addition, Filter 754 in Figure 7B is defined by 
Filter Type 768. Filter Type 768 includes a value, which 
is compared to a key using a condition operator. The 
condition operator is defined by SQLConditionOperatorType 
770. SQLConditionOperatorType 770 is represented by 
block 772 and includes condition operators, such as 
equal, greater than, less than, less than or equal to, 
greater than or equal to, not equal to, etc. For 
example, a client may send a request to retrieve 
information for a ProblemTicket . id that is not equal to 
L. ProblemTicket . id is the object key, L is the value, 
and not equal to is the condition operator. The key, 
value and the condition operator are also part of the SQL 
statement that will be generated by the adaptor. 

Thus far we have discussed what a request XML 
message consists of. We now turn to a discussion of a 
response XML message. A response is defined by^ ; 
Transact ionResponseType 774 . Transact ionResponseType 
774*7 similar to TransactionRequestType 712 in Figure 7A, 
also includes a TransactionType and a ProviderType . 
However, Transact ionResponseType 774 also includes a 
body, defined by ResponseBodyType 776, which is extended 
by ESMResponseBodyType 706 in Figure 7A. Moreover, 
TransactionResponseType 774 includes ErrorCode 778. 

With reference to Figure 7D, a diagram illustrating 
an example implementation of etcml.xsd is depicted in 
accordance with a preferred embodiment of the present 
invention. Figure 7D is part of etcml.xsd in 
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continuation of Figure 7C. ErrorCode 778 shown in Figure 
7C is defined by block 780. ProviderErrorCodeType 780 
describes a set of error messages that may be returned to 
the client in a response. A default value 782 of 0 may 
be returned for a successful response and default value 
786 of 10000 may be returned for a system failure 788. 
The client may further customize the error messages using 
etcml_redef ines. xsd schema, which is described in further 
details in Figure 8. 

Turning now to Figure 8, a diagram illustrating an 
example implementation of etcml_redef ines .xsd is depicted 
in accordance with a preferred embodiment of the present 
invention. As depicted in Figure 8, etcml_redef ines .xsd 
800 includes ProviderActionType 820, which allows a 
client to perform a number of actions. In this example, 
clients are allowed to perform add, delete, get, list, 
validate and modify actions. These actions are described 
further below: 

The add action creates a new record for the selected 
object. The object is unlocked once it is created to 
allow modification. "* 

The delete action -deletes an existing record for the 
selected object. For example, a ProblemTicket . Person 
object or objects within ProblemTicket may be deleted. 
The get action allows a client to retrieve an existing 
record for the selected object. If no object matches the 
criteria, an error code of 0 is returned. Results of a 
get action may include nested objects. Get action also 
provides a LockObject property to the recipient of the 
object, so that the object may be locked for update. 
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The list action returns a list of requested fields, 
such as ProblemTicket.id, after matching filter criteria 
of the request. If no object matches the criteria, an 
error code of 0 is returned. Similar to the get action, 
the list action may return nested objects. 

The modify action allows a client to update an 
existing record for the selected object. An object has 
to be unlocked or already locked by the client in order 
to be modified. 

The validate action applies a filter against an 
object key and a value using a condition operator, such 
as equal to, not equal to, etc. The error code is non- 
zero if the validation fails. If validation succeeds, 
the result includes the value of the object key, if the 
object key is case- insensitive . Thus, the client may 
obtain the actual value of the object key as it is a 
requested field. 

Etcml_redef ines .xsd 800 also includes a 
ProviderErrorCodeType. 822, which defines a range of error 
codes to be returned to the client. In this example, a 
range of 0 to 12000 of valid error code values are 
allowed. 

Turning next to Figure 9, a flowchart illustrating 
an exemplary process for generating SQL statements at 
runtime from a generic XML request or response message is 
depicted in accordance with a preferred embodiment of the 
present invention. As depicted in Figure 9, the process 
begins when the client, such as client 402 in Figure 4, 
sends a request for information to the server (step 902) . 
The server, such as Web server 408 in Figure 4, assembles 



24 

Docket No. AUS920030928US1 

the XML request message (step 904) according the format 
defined by the generic XML schemas. Once the XML message 
is assembled, the server sends the request XML message to 
adaptor 410 (step 906) . 

Next, adaptor 410 generates an SQL statement using 
the values from the assembled XML message (step 908) . 
Once the SQL statement is generated, the adaptor executes 
the SQL statement (step 910) against the data store to 
obtain the information. Once the result is returned from 
the data store, adaptor 410 sends the result to the 
server in a response XML message (step 912) . The server 
then disassembles the response XML message into return 
values according to the set of generic schemas (step 
914) . 

Finally, the server sends the return values to the 
client with the requested information (step 916) . The 
process terminates thereafter. 

Turning now to Figure 10, a 'diagram illustrating an 
example XML request message is depicted in accordance 
with a preferred embodiment of the "present invention. As 
depicted in Figure 10, in this example implementation, 
request XML message 1000 includes^ Transaction 1002. 
Transaction 1002 including a Request 1004 to perform a 
list action, as described by Transact ionType 1006, 
against data store with SystemID 1008' of u eESM630" . 
Request 1004 includes a set of Parameters 1010. 
Parameter 1010 includes an attribute parametertype 1011 
defined by ParametersType 1011 in esmBase.xsd as 
described in Figure 6A and 6B. 
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Parameters 1010 includes two RequestedFields, namely 
ProblemTicket . id 1012 and ProblemTicket . Person. id 1014. 
Parameters 1010 also includes a StartRow 1016 with a 
value of 1 and a DisplayRowCount 1018 with a value of 10, 
which defines a request of rows 1 through 10 for the 
RequestedFields values. In this example, request 1004 
is a custom request, which includes Filters 1020. 
Filters 1020 filters the results using condition join 
operator * AND' 1022, a value 1024 of L, and a condition 
operator 1026 of "NotEqualTo" against the object key of 
ProblemTicket . id 1026. 

Turning to Figure 11, a diagram illustrating an 
example generated SQL statement and a response using a 
response XML message is depicted in accordance with a 
preferred embodiment of the present invention. As 
depicted in Figure 11, in this example implementation, 
the SQL statement generated by the adaptor from request 
1004 in Figure 10 is shown as SQL statement 1101. 

Statement 1101 is a SELECT clause, where the table 
name for ProblemTicket is Problems 1102. The column name 
of requested field ProblemTicket . id 912 in Figure 9 is 
PROBLEM_ID 1104 and the column name of requested field 
ProblemTicket. Person. id 914 in Figure 9 is 
FIRST_PEOPLE_ID 1106. In addition, the real data store 
name is TSD630UC 1108, as opposed to eESM630 908 in 
Figure 9. The WHERE clause includes filtering of 
PROBLEM_ID 1110 against the value of X L' 1112. 

After adaptor executes statement 1101, a response is 
returned using response XML message 1120. Response XML 
message 1120 includes Transactions 1122. Transactions 
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1122 includes Response 1124 for a list action, as 
described by Transact ionType 1126, against data store 
with SystemID n eESM630" 1128. Response 1124 is 
successful as described by ResponseDescription 1130 with 
an ErrorCode 1132 of 0. Within Response 1124, a Body 
1134 includes a RowSet 1136, with a fetch count of 201. 
The fetch count indicates the number of records returned 
in this object, in this example, the object is the 
ProblemTicket 1137. Next, each record is represented by 
a Row 1138. Within Row 1138, there are 2 columns, column 
1139 and column 1141. 

Column 1139 includes name 1140 and a value 1142. 
Name 1140 represents ProblemTicket . id, which is the 
RequestedField. Value 1142 represents *SITEA-00000034' , 
which is returned from the data store. 

Column 1141 also includes name 1144 and value 1146. 
Name 1144 represents ProblemTicket . Person. id, which is 
another RequestedField. Value 1146 represents 470000003, 
which is returned from the data store. Block 1148 
represents the second record* of* the result returned from 
the data store. >' 

Thus, using the generic 'and abstract XML request and 
response messages of the present invention, a client may 
interact with the data store to retrieve or submit 
information about an object without knowledge of how to 
access or interact with the data store. In addition, the 
present invention supports different types of data store 
without requiring development of a special XML schema 
definition or APIs. Furthermore, the present invention 
supports complex objects, such as nested lists or nested 
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objects. The generic nature of the XML schemas reduces 
the amount of code required to support other possible 
requests . 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system, those of ordinary 
skill in the art will appreciate that the processes of 
the present invention are capable of being distributed in 
the form of a computer readable medium of instructions 
and a variety of forms and that the present invention 
applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 
distribution. Examples of computer readable media 
include recordable -type media, such as a floppy disk, a 
hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and 
transmission- type media, such as digital and analog 
communications links, wired or wireless communications 
links using transmission forms, such as, for example, 
radio frequency and light wavfeV transmissions . The 
computer readable media may' 1 take the form of coded 
formats that are decoded for actual use in a particular 
data processing system. $ 

The description of the present invention has been 
presented for purposes of illustration and description, 
and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. The embodiment was chosen and described in 
order to best explain the principles of the invention, 
the practical application, and to enable others of 
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ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 
suited to the particular use contemplated. 



